The present invention relates to a system and method for automated financial transaction processing and, more specifically, to a system and method for processing financial transaction data, including payment, refund, and loan funding data, using a standard web browser in which the system automatically updates, from a group of account processors, the account processor associated with a particular account.
Extensive manual effort is often involved to properly locate and apply a payment (or data corresponding to a financial transaction) to an account in the case where a financial or payment processing institution maintains multiple payment or other financial transaction accounting systems, especially loan payment systems. This situation results from debtors who wish to make a payment to their account, but do not have their payment stub, have an incomplete account number, or have only an account number with no other means of identifying which of the payment systems their account is based. These types of payments are referred to herein as miscellaneous payments.
Tellers or other individuals who interact with customer account holders are often too busy and do not have access to the tools necessary to investigate which processing system is associated with the customer's account. In this case, the teller typically sets the payment aside for manual processing by an operator whose responsibility it is to determine which payment system maintains the account associated with the customer's payment. The operator is typically located at a site remote from the teller's branch, and services many groups of miscellaneous payments from a large region.
A typical procedure employed by financial transaction or payment system owners to process miscellaneous payments and financial transactions including loan funding, loan refunds, and other payables will be described with reference to FIG. 1. In order to determine the financial transaction system associated with a particular account, one or more operators 2 must use one or more terminals 4 to log into each account processor 6 and search for a valid account. Account processors 6 are typically mainframe based programs used to track debit and credit transactions such as loan balances, payments thereto and refunds. Once a valid account is located, operator 2 must then process the payment or refund.
To process the payment, operator 2 first applies a credit to the account in the amount of the payment. Operator 2 prepares a magnetic ink character recognition (MICR) encoded proof ticket, and forwards the remittance provided by the customer such as the check or cash substitute payment slip and the proof ticket to the department responsible for ensuring that the loan owner, i.e., bank, receives payment from the customer's checking account (hereinafter “demand deposit account” or “DDA”) or credit card account owner.
Once the payment data has been entered into the appropriate account processor 6 and the remittance and proof ticket forwarded to the appropriate department, operator 2 must then access the payment system owner's general ledger 8 and make one or more updating entries. General ledger 8 is typically a computer based program and database used to track corporation-wide accounting activity. General ledger 8 typically resides on a mainframe computer.
This process requires that each operator 2 have knowledge of the back end systems, i.e., account processor 6, and how to access and operate these systems. The above-described process is inefficient, requiring operators 2 to individually access multiple account processors 6, search for a valid account number in that system, individually apply payments to those systems, and subsequently access and update general ledger system 8. This level of activity decreases the quantity of miscellaneous payments which can be processed by operator 2 and leads to payment processing errors.
In addition, terminal 4 is typically a mainframe terminal or a personal computer (“PC”) running mainframe emulation software. Depending on the particular networking environment of the processing system owner, terminal 4 can have dedicated access to only one or a subset of the systems. In this case, user 2 must move from terminal 4 to a different terminal 4 in order to determine which system is associated with an account number. In the case where terminal 4 has access to multiple account processors 6, each operator 2 must still separately log into each processor 6 to determine account association. These multiple logins further decrease operator payment processing efficiency.
It is therefore desirable to have a financial transaction processing system which can automatically determine which account processor 6 a particular payment is associated with, automatically update that system and automatically make the proper accounting treatment entries to general ledger 8. It is also desirable to have a financial transaction processing system which does not require that operator 2 have any special knowledge of the underlying account processors 6.
Special data entry application software is often required in the case where terminal 4 is a PC running mainframe emulation software. As a result, technicians are required to visit each terminal 4 to upgrade data entry applications, terminal emulators and keystroke macros. Also, the use of special emulation software requires particularized operator training such that operator 2 must be trained as to the operation of the software in addition to the processing institution's payment processing procedures. This creates significant expense for the system owner and adds to the inefficiency of payment processing.
In an effort to avoid visits by technicians to terminals 4, systems have been developed which push, i.e., roll out, the application software from a central computer to a permanent storage device within terminal 4 when the terminal is turned on or when an operator logs onto the system. Application roll out is typically used to push software updates to terminal 4. This type of roll out, however, is problematic because pushing applications to a terminal is highly error prone and sensitive to the hardware and software configuration of the terminal. As a result, roll outs often fail and a technician is forced to visit the terminal to complete the software installation and resolve any other problems caused by the failed roll out.
It is therefore also desirable to have an interface on terminal 4 for operator 2 which does not require special customized data entry application software or multiple visits by technicians to upgrade this software, and which does not require specialized training to use (other than the actual payment processing procedures).